To manage the complexity of long computer programs, computer programmers often adopt object-oriented programming techniques. With these techniques, a computer program is organized as multiple smaller modules called objects. An object is a unit of code comprising both routines and data and is thought of as a discrete entity. These objects perform specified functions and interact with other objects in pre-defined ways. Objects communicate with each other through interfaces. Each object may have multiple interfaces. An interface exposes and defines access to the object's public routines and data. Put another way, an interface can be considered as the definition of an expected behavior and expected responsibilities. One of the advantages to interfaces is that a client object can continue to access the methods of a server object that are exposed through the interface, regardless of whether the underlying code in the object is updated or changed for another reason.
One of the primary benefits of object-oriented programming is that the objects can be easily and affordably adapted to meet new needs by combining them in a modular fashion. The structural foundation for an object-oriented language is the object model. The Component Object Model (COM) produced by Microsoft Corporation of Redmond, Wash., is an example of an object model.
A typical compiler is a computer program that translates a high-level programming language into machine language. The compiler usually converts the high-level language into assembly language first, and then translates the assembly language into machine language. The program fed into the compiler is called the source code; the generated machine language program is called the object code. The compiler looks at the entire piece of source code and collects and reorganizes the instructions.
A conventional compiler or code editor, such as the Visual Basic Code Editor, produced by Microsoft Corporation, indicates a code error to a user by underlining the offending code with a squiggle or other indicator, for example, and/or inserting a line number and class of the error in a tasklist or other window or dialog box. However, the error information is very broad, and is often not sufficient for users to identify the specific cause of the error. Although general information is available about a given error in code, such error information is limited to an error number and a brief string of text describing the error in broad terms. This error information may not be specific enough to help the user identify the problem quickly, particular in the case of novice users.
Because the error information is very general, it can furthermore often be misleading to the user. For example, the ultimate cause of the error might be omission rather than commission. Thus, in some cases, changing code elsewhere in the program code might be the proper way to correct the error, rather than changing code where the error was flagged. Even the online help information which describes the error type in more detail is often not sufficient to help the user correct the error, because it is generally not specific to the user's situation. All of this combines to frustrate and slow down the user.
In view of the foregoing, there is a need for systems and methods that overcome the limitations and drawbacks of the prior art.